1. Technical Field
This invention relates generally to data processing systems and, more particularly, to resource sharing among data processing systems with password synchronization. More specifically still, the present invention relates to providing password synchronization between a general repository to a plurality of local resources for each user within a client/server system.
2. Related Prior Art
Computer networks are well known in the arts and continue to grow in both size and complexity. This growth is fueled by more computers being connected to networks and connecting networks to other networks. This is done in order to enable computers to work together efficiently, to simplify sharing resources such as files, applications, printers, and even special computers.
Unfortunately, many networks contain computers from different manufacturers, which complicates the task of getting computers to work together efficiently. Computers in such "multi-vendor" networks are usually difficult to operate together because they do not use common data formats or common security mechanisms. The lack of a common network naming scheme also limits the degree to which computers can share information.
In order to overcome many of the above problems, the Open System Foundations ("OSF") Group has been formed that has developed the Distributed Computing Environment ("DCE") that transforms a group of networked computers into a single, coherent computing engine. DCE masks differences among different kinds of computers, thereby enabling users to develop and execute distributed applications that can tap into a network's latent power, using widespread resources such as storage devices, CPU's, and memory. Because distributed parts of these applications can execute concurrently, they can be much more powerful than single processor applications that must act on data sequentially.
Unfortunately, even distributed computing environments have their own problems such as how to protect data that must be shared among multiple users. Additionally, events must be synchronized between separate computers and computers with differing data formats and file-naming schemes must be allowed to work cooperatively one with another. DCE overcomes many of these problems and provide solutions to these vexing issues.
DCE is well known in the industry, an example of such is shown in FIG. 1. FIG. 1 is a block diagram of DCE application programming interface 1 that provides for a DCE file service 3. DCE is a layer of software that masks differences between various kinds of hosts. As a layer, it sits on top of a host operating system 5 and networking services for network transport 7. The DCE distributed services, which include security 9, directory 11, and time 13, remote procedure call ("RPC") 15 and thread services 17. RPC 15 and threads 17 are base DCE services that are available on every system on which DCE is installed. FIG. 1 further shows how the DCE file service is similar to an application that uses the underlying DCE services for distribution. DCE directory service further consists of a cell directory service 19 ("CDS") and a global directory service ("GDS") 21, which programs use by calling the directory service ("XDS") application programming interface ("API").
Typically, each user must first prove his or her identity by using a secret password to log onto the local host. The local host uses the password, which is known only to the user and the local host, as proof that the user is who he or she claims to be. Once the user logs onto the local host, the host resources are usually protected further by means of permissions or privileges associated with each file. The permissions regulate whether a user can read, write or execute that file. The number of users on a single local host is typically small enough so that the host alone can manage all of the passwords and permission functions.
A distributed computing environment, on the other hand, might support thousands of users accessing files on any of hundreds or thousands of local hosts in the environment. Because it is impractical to maintain every DCE user's security information on every host in the environment, DCE serves security information from a centralized database. This database, along with a distributed set of daemons and libraries, compose the DCE security service.
When servers enforce security, each client must provide its user's identity and access rights. These are provided on the first RPC call, and sometimes in highly secure environments, on every RPC call. Because access to every DCE resource--directories, files, printers, and so on--is controlled by a server, the server's demands for authentication and authorization require comprehensive network security. This applies to DCE servers, such as those of the CDS, as well as user application servers. The server verifies the clients' authenticity and authorization before allowing access to the resource.
Typically, security service functions are built into applications. This means that the clients call local security routines to request authentication information from a security server and pass it to other servers. Servers also call security routines to verify authentication information and enforce authorization. Authentication is the ability to prove one's identity to someone else. Authorization is the ability to regulate access based on one's identity. Passwords are used to ensure authenticity and then to gain authorization.
In DCE, the security service, which is also known as a registry, serves as a single source of security and manages information about users, groups, and the like. This gives a company a single place to define and manage users. One limitation to this approach is the propagation of passwords. Most registries only store an encrypted version of the user's password. Often, though, the encryption mechanism at each registry is different than any of the other registries, especially in a system where dissimilar registries from different vendors are being used. Thus, a password encrypted by the DCE registry may be unusable by another registry manufactured by someone other than the vendor of the DCE main registry. Accordingly, it would be beneficial to be able to propagate the plain-text password securely from the DCE registry to registries that synchronize with the DCE registry so that other registries can then encrypt the password in their own format. This would allow a user to avoid having multiple passwords, typically one for security registry, and avoid the necessity of updating these passwords manually in each registry to insure they are consistent across all security registries.
Further, the DCE registry does not provide a way of populating a new non-DCE or foreign registry that wishes to populate its database with users and passwords from the DCE registry. This is because the DCE itself typically only stores encrypted passwords and the new registry cannot obtain the plain-text passwords it needs to populate its database until an update occurs to a given user's password. Accordingly, it would be beneficial to provide a system that overcomes the prior problem of not being able to propagate passwords to new registries until an update to a given user's password has occurred.